1. Field of the Invention
The present invention relates to interoperability between IPv4 nodes via IPv6 networks. In particular, the present invention relates to enabling a first IPv4 node of a first private network to connect with a second IPv4 node of a second private network, via an IPv6 access network, without the necessity of tunneling between the first and second private networks.
2. Description of the Related Art
Virtual private networks (VPNs) have become an increasingly popular technique for enabling host computers to remotely access a corporate network in a secure manner. VPN connections enable users of the host computers to enjoy advantages such as telecommuting, reducing the reliance of corporate network access using an on-site host computer. Efforts are underway by the Layer 3 Virtual Private Networks (13vpn) Working Group to provide solutions for supporting provider-provisioned Layer-3 (routed) Virtual Private Networks (L3VPNs).
Conventional VPNs have relied on connections via the Internet, implemented as a public IPv4 network. However, such reliance introduces numerous well known performance issues, including bandwidth and latency limitations, and potential exposure to unreliable and malicious entities, especially in cases where queries need to be sent (e.g., Domain Name Service (DNS) queries) need to be sent to locate a destination VPN server providing the VPN service.
Additional problems arise in cases where a VPN connection is attempted via an access network, for example in the cases where an IPv4 host computer in a private network attempts to access a destination via an IPv6 access network. Proposals are underway by the Next Generation Transition (NGTRANS) Working Group of the Internet Engineering Task Force (IETF), renamed as the IPv6 Operations (v6ops) Working Group, to enable network nodes to transmit IP packets, generated according to IPv6 protocol as specified by the Request for Comments (RFC) 2460, across an IPv4 network. For example, RFC 3056 proposes an interim solution (referred to herein as “the 6 to 4 proposal”) of sending IPv6 packets as payload for IPv4 packets, where an interim unique IPv6 address prefix is assigned to any node that has at least one globally unique IPv4 address. The 6 to 4 proposal specifies that an IPv6 node has an IPv6 address that contains an assigned IPv4 address, resulting in an automatic mapping between the IPv6 and IPv4 addresses. Hence, the IPv6 node can easily encapsulate the IPv6 packet with an IPv4 header based on extracting the assigned IPv4 address from within its IPv6 address.
Concerns arise in the event that an IPv6 node is coupled to a private IPv4 network having a Network Address Translator (NAT). NATs perform a Layer-3 translation of IP-Addresses, so that public Internet addresses map to private IP addresses, as described in detail by the Request for Comments 1918 (RFC 1918). This mapping has allowed enterprises to map a large number of private addresses to a limited number of public addresses, thus limiting the number of public addresses required by Internet users.
As described in RFC 3056, however, if an IPv6 node is coupled to an IPv4 network having a NAT, then the NAT box “must also contain a fully functional IPv6 router including the 6 to 4 mechanism” in order for the 6 to 4 proposal to still be operable in the IPv4 network having the NAT. However, the modification of existing NATs to include IPv6 routers to include the 6 to 4 mechanism may not be a practical solution.
Further, the IPv4 addresses of the 6 to 4 protocol are assumed to be global public addresses. Hence, if an IPv6 node (i.e., a correspondent node) wants to communicate with a roaming mobile IPv6 node, the 6 to 4 address of the roaming mobile IPv6 node must be a global public address, not a private address.
Another NAT-based proposal for enabling IPv4 hosts in an IPv4 network to access IPv6 hosts in an IPv6 network is described in RFC 2766, entitled “Network Address Translation—Protocol Translation (NAT-PT). The NAT-PT provides a combination of network address translation and protocol translation based on a pool of IPv4 addresses for assignment to IPv6 nodes on a dynamic basis as sessions are initiated across IPv4-IPv6 boundaries. However, the description of the NAT-PT in the RFC 2766 assumes that IPv4 addresses are unique.
Commonly-assigned, copending application Ser. No. 10/875,811, filed Jun. 25, 2004, entitled “ARRANGEMENT FOR REACHING IPv4 PUBLIC NETWORK NODES BY A NODE IN AN IPv4 PRIVATE NETWORK VIA AN IPv6 ACCESS NETWORK,” the disclosure of which is incorporated in its entirety herein by reference, describes an arrangement that enables an IPv4 node to access an IPv4 public network via an IPv6 access network. The IPv4 node is able to send an IPv4 packet to an IPv4 destination via the IPv6 access network, based on translation of the IPv4 packet into an IPv6 packet for transmission via the IPv6 access network. The IPv4 packet is translated into the IPv6 packet by a local gateway. The IPv6 packet has an IPv6 source address that includes a prescribed address prefix assigned to the local gateway, and an IPv4 address of the IPv4 node. The IPv6 packet also includes an IPv6 destination address that includes a second address prefix assigned to a remote gateway, and a second IPv4 address of the IPv4 destination. The IPv6 packet is converted by the remote gateway into an IPv4 packet for reception by the IPv4 destination via an IPv4 network. Hence, the IPv4 node is able to communicate with an IPv4 destination residing on another IPv4 network via the IPv6 access network, without the necessity of generating an IPv6 tunnel between the local gateway and the remote gateway.